The present invention relates generally to electronic mail (e-mail) systems and, more particularly, to improved methodology for supporting relaying of e-mail messages in a Message Transfer Agent, particularly by “roaming” users (i.e., users outside a company's firewall or administrative domain).
Today, electronic mail or “e-mail” is a pervasive, if not the most predominant, form of electronic communication. FIG. 1 illustrates the basic architecture of a typical electronic mail system 10. At a high level, the system includes a mail server connected over a network to various e-mail “clients,” that is, the individual users of the system. More specifically, the system 10 includes one or more clients 11 connected over a network to at least one SMTP (Simple Mail Transport Protocol) server or “Message Transfer Agent” (MTA) 12a for routing e-mail. Users write, send, and read e-mail via Mail User Agents (MUA), such as Microsoft Outlook™ or mutt, present at each client (computer). To send e-mail, an MUA connects to an MTA which receives the e-mail and routes it to another MTA. An intermediary MTA might forward the e-mail to yet another MTA until the e-mail reaches the destination system, where the e-mail is stored in a mailbox accessible by the recipient.
A typical e-mail delivery process is as follows. In the following scenario, Larry sends e-mail to Martha at her e-mail address: martha@example.org. Martha's Internet Service Provider (ISP) uses an MTA, such as provided by Sendmail® for NT, available from Sendmail, Inc. of Emeryville, Calif. (With a lower case “s,” “sendmail” refers to Sendmail's MTA, which is one component of the Sendmail® Switch product line.)    1. Larry composes the message and chooses Send in Microsoft Outlook Express (a “Mail User Agent” or MUA). The e-mail message itself specifies one or more intended recipients (i.e., destination e-mail addresses), a subject heading, and a message body; optionally, the message may specify accompanying attachments.    2. Microsoft Outlook Express queries a DNS server for the IP address of the local mail server running sendmail. The DNS server translates the domain name into an IP address, 10.1.1.1, of the local mail server.    3. Microsoft Outlook Express opens an SMTP connection to the local mail server running sendmail. The message is transmitted to the sendmail server using the SMTP protocol.    4. sendmail queries a DNS server for the MX record of the destination domain, i.e., example.org. The DNS server returns a hostname, e.g., mail.example.org. sendmail queries a DNS server for the A record of mail.example.org, i.e., the IP address. The DNS server returns an IP address 127.118.10.3.    5. sendmail opens an SMTP connection to the remote mail server providing e-mail service for example.org which is also running sendmail. The message is transmitted to the sendmail server using the SMTP protocol.    6. sendmail delivers Larry's message for Martha to the local delivery agent. It appends the message to Martha's mailbox. By default, the message is stored in:            /var/spool/mail/martha.            7. Martha has her computer dial into her ISP.    8. Martha chooses Check Mail in Eudora.    9. Eudora opens a POP3 (Post Office Protocol version 3, defined in RFC1725) connection with the POP3 (incoming mail) server. Eudora downloads Martha's new messages, including the message from Larry.    10. Martha reads Larry's message.
The MTA, which is responsible for queuing up messages and arranging for their distribution, is the workhorse component of electronic mail systems. The MTA “listens” for incoming e-mail messages on the SMTP port, which is generally port 25. When an e-mail message is detected, it handles the message according to configuration settings, that is, the settings chosen by the system administrator, in accordance with relevant standards such as Request For Comment documents (RFCs). Typically, the mail server or MTA must temporarily store incoming and outgoing messages in a queue, the “mail queue.” Actual queue size is highly dependent on one's system resources and daily volumes.
MTAs, such as the commercially-available Sendmail® MTA, perform three key mail transport functions:                Routes mail across the Internet to a gateway of a different network or “domain” (since many domains can and do exist in a single network)        Relays mail to another MTA (e.g., 12b) on a different subnet within the same network        Transfers mail from one host or server to another on the same network subnet.To perform these functions, it accepts messages from other MTAs or MUAs, parses addresses to identify recipients and domains, resolves aliases, fixes addressing problems, copies mail into a queue on its hard disk, tries to process long and hard-to-pass messages, and notifies the sender when a particular task cannot be successfully completed. The MTA does not store messages (apart from its queue) or help users access messages. It relies on other mail system components, such as message delivery agents, message stores and mail user agents (MUAs), to perform these tasks. These additional components can belong to any number of commercial or free products (e.g., POP3 or IMAP servers, Microsoft Exchange, IBM Lotus Notes, Netscape, cc:Mail servers, or the like). Because of its central role in the e-mail systems, however, the MTA often serves as the “glue” that makes everything appear to work together seamlessly.        
The overall process may be summarized as follows. E-mail is routed via SMTP servers, the so-called “Mail Transfer Agents” (MTA). Users write, send, and read e-mail via Mail User Agents (MUA). To send e-mail, an MUA connects to an MTA which receives the e-mail and routes it to another MTA. An intermediary MTA might forward the e-mail to yet another MTA until the e-mail reaches the destination system, where the e-mail is stored in a mailbox accessible by the recipient.
For further description of e-mail systems, see e.g., Sendmail® for NT User Guide, Part Number DOC-SMN-300-WNT-MAN-0999, available from Sendmail, Inc. of Emeryville, Calif., the disclosure of which is hereby incorporated by reference. Further description of the basic architecture and operation of e-mail systems (including TLS, as described in further detail below) is available in the technical and trade literature; see e.g., the following RFC (Request For Comments) documents:    RFC821 Simple Mail Transfer Protocol (SMTP)    RFC822 Standard for the Format of ARPA Internet Text Messages    RFC974 Mail Routing and the Domain System    RFC1123 Requirements for Internet Hosts—Application and Support    RFC1725 Post Office Protocol version 3 (POP3)    RFC2033 Local Mail Transfer Protocol (IMP)    RFC2060 Internet Message Access Protocol (IMAP), Ver. 4, rev. 1    RFC2246 The TLS protocol, version 1.0    RFC2487 SMTP service extension for secure SMTP over TLScurrently available via the Internet (e.g., at ftp://ftp.isi.edu/in-notes), the disclosures of which are hereby incorporated by reference. RFCs are numbered Internet informational documents and standards widely followed by commercial software and freeware in the Internet and UNIX communities. The RFCs are unusual in that they are floated by technical experts acting on their own initiative and reviewed by the Internet at large, rather than formally promulgated through an institution such as ANSI. For this reason, they remain known as RFCs even once they are adopted as standards.
In an e-mail system, the system must identify its users to ensure safe usage of the system. In a typical configuration, an MTA exists on a company's local area network and, from the location, sends mail to and receives mail from users, including of course users that are outside to the local area network. Some of those users, particularly “remote” employees, may be communicating with the MTA via the Internet. When an MTA receives from an external user (i.e., outside its current domain) mail which is intended to be forwarded to another location (i.e., again, outside the current domain), the MTA must decide whether it can in fact safely forward or relay that mail to the other location. This is particularly a problem for remote or “roaming” users—that is, users that want to use a particular MTA (e.g., because of certain properties)—who must send e-mail from an external source via the particular MTA to another external source. Typically, these are users who are connecting in a manner such that they cannot be identified or authenticated via an LP address or e-mail address.
As basic SMTP does not provide any authentication, it is common practice for MTAs to accept e-mail from any source and send it to any recipient. This open architecture has been abused by people who send unsolicited e-mail (UBE) to many recipients via third-party MTAs, thus stealing resources (e.g., bandwidth and storage).
A very simple approach to address this problem is to allow only trusted hosts (e.g., recognized via IP address or hostname) to use an MTA for relaying. However, this does not address the problem for “roaming” users—that is, users who may connect from different, untrusted, or unknown IP addresses. Therefore, more sophisticated approaches have been attempted.
Two methods in common use to allow relaying based on some form of authentication are “POP before Relay” and “SMTP AUTH”. Each has its own set of distinct disadvantages, however. Regarding the first approach, POP is a message access protocol which requires authentication. The IP address belonging to the authenticated entity is stored in a database with a timestamp. This database is used by the MTA to allow (for a limited time) full access, including relaying. However, that approach has problems. For instance, users must use POP to read or at least access the POP server before sending e-mail. Further, the timeout can be too short or too long and hence either cut off a user and require her/him to re-authenticate via POP, or allow another (unauthenticated) user to accidently access the MTA. Regarding the second approach, SMTP AUTH is defined in RFC2554 which is based on SASL as described in RFC2222. The possible problems with this method include lack of support in MUAs as well as fairly insecure authentication mechanisms (e.g., using clear text passwords).
What is needed is an easy way for e-mail systems to determine when it is appropriate to relay e-mail messages, particularly from “roaming” users. At the same time, however, the system should safeguard against relaying attempts by unauthorized users. The present invention fulfills this and other needs.